---
layout: default
category: tot
---

<p>The <b>Chrome DevTools Protocol</b> allows for tools to instrument, inspect, debug and profile Chromium, Chrome and other Blink-based browsers.
Many existing projects <a href="https://developer.chrome.com/devtools/docs/debugging-clients">currently use</a> the protocol.
The <a href="https://developers.google.com/web/tools/chrome-devtools/">Chrome DevTools</a> uses this protocol and the team maintains its API.

<p>Instrumentation is divided into a number of domains (DOM, Debugger, Network
etc.). Each domain defines a number of commands it supports and events it
generates. Both commands and events are serialized JSON objects of a fixed
structure. You can either <a href="https://developer.chrome.com/devtools/docs/debugger-protocol">debug
over the wire</a> using the raw messages as they are described in the corresponding domain
documentation, or use <a href="https://developer.chrome.com/devtools/docs/debugger-protocol#extension">extension
JavaScript API.</a></p>


<h3>Protocol API Docs</h3>
<h4><a href="tot/">The latest (tip-of-tree) protocol (tot)</a></h4>
<p> It <a href="https://chromium.googlesource.com/chromium/src/+log/master/third_party/WebKit/Source/core/inspector/browser_protocol.json">changes</a>
<a href="https://chromium.googlesource.com/chromium/src/+log/master/third_party/WebKit/Source/platform/v8_inspector/js_protocol.json"></a>frequently</a> and can break at any time. However it captures the full capabilities of the Protocol, whereas the stable release is a subset. There is no backwards compatibility support guaranteed for the capabilities it introduces.</p>

<h4><a href="v8/">v8-inspector protocol (v8)</a></h4>
<p>It is available in <a href="https://nodejs.org/en/blog/release/v6.3.0/">node 6.3+</a> and enables <a href="https://medium.com/@paul_irish/debugging-node-js-nightlies-with-chrome-devtools-7c4a1b95ae27">debugging & profiling</a> of Node.js apps.</p>

<h4><a href="1-2/">stable 1.2 protocol (1-2)</a></h4>
<p>The stable release of the protocol, tagged at Chrome 54. It includes a smaller subset of the complete protocol compatibilities.

<h3>Resources</h3>
<p>Consider subscribing to the <a href="https://groups.google.com/d/forum/chrome-debugging-protocol">chrome-debugging-protocol</a> mailing list.
<p>The <a href="https://github.com/chromedevtools/devtools-protocol">devtools-protocol repo</a> issue tracker can also be used for concerns with the protocol. It also hosts the canonical copy of the json files.
<p>Useful: <a href="https://developers.google.com/web/updates/2017/04/headless-chrome">Getting Started with Headless Chrome</a> and the <a href="https://chromium.googlesource.com/chromium/src/+/lkgr/headless/README.md">Headless Chromium readme</a>.
<p>The <a href="https://github.com/cyrus-and/chrome-remote-interface/">chrome-remote-interface</a> node module is recommended, and its <a href="https://github.com/cyrus-and/chrome-remote-interface/wiki">wiki</a> and <a href="https://github.com/cyrus-and/chrome-remote-interface/issues?utf8=%E2%9C%93&q=is%3Aissue%20">issue tracker</a> are full of useful recipes.
<p>The <a href="https://github.com/ChromeDevTools/awesome-chrome-devtools#chrome-devtools-protocol">awesome-chrome-devtools</a> page links to many of the tools in the protocol ecosystem, including protocol API libraries in JavaScript, TypeScript, Python, Java, and Go.


Many applications and libraries already use the protocol.

<h3 id="remote">Basics: Using DevTools as protocol client</h3>
<p>The Developer Tools front-end can attach to a remotely running Chrome instance for debugging.

  For this scenario to work, you should start your
  <i>host</i> Chrome instance with the remote-debugging-port
  command line switch:
</p>

<pre class="summary">
chrome.exe --remote-debugging-port=9222</pre>

<p>Then you can start a separate <i>client</i> Chrome instance, using a distinct user profile:</p>

<pre class="summary">
chrome.exe --user-data-dir=&lt;some directory&gt;</pre>

<p>Now you can navigate to the given port from your <i>client</i> and attach to
  any of the discovered tabs for debugging: <a href="http://localhost:9222">http://localhost:9222</a>
</p>

<p>You will find the Developer Tools interface identical to the embedded one and
  here is why:
</p>
<ul>
  <li>When you navigate your <i>client</i> browser to the remote's Chrome port,
    Developer Tools front-end is being served from the <i>host</i> Chrome
    as a Web Application from the Web Server.
  </li>
  <li>It fetches HTML, JavaScript and CSS files over HTTP
  </li>
  <li>Once loaded, Developer Tools establishes a Web Socket connection to its
    host and starts exchanging JSON messages with it.
  </li>
</ul>

<p>In this scenario, you can substitute Developer Tools front-end with your
  own implementation. Instead of navigating to the HTML page at
  http://localhost:9222, your application can discover available
  pages by requesting: <a href="http://localhost:9222/json">http://localhost:9222/json</a> and getting a JSON object with information about inspectable pages along
  with the WebSocket addresses that you could use in order to start
  instrumenting them.
</p>

<p>Remote debugging is especially useful when debugging remote
  instances of the browser or attaching to the embedded devices. Blink port
  owners are responsible for exposing debugging connections to the external
  users.
</p>

<p>If you need the protocol version for a specific Chrome client, glance at <code>fetchFromChromeRepo</code> from chrome-remote-interface's <a href="https://github.com/cyrus-and/chrome-remote-interface/blob/master/lib/devtools.js"><code>devtools.js</code></a>.




<h3>Sniffing the protocol</h3>
<p>This is especially handy to understand how the DevTools frontend makes use of the protocol.
  First, run Chrome with the debugging port open:
<pre>
alias canary="/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary"
canary --remote-debugging-port=9222 http://localhost:9222 http://chromium.org</pre>

  Then, select the Chromium Projects item in the <em>Inspectable Pages</em> list. Now that DevTools is up and fullscreen, open DevTools to inspect it.
  Cmd-R in the new inspector to make the first restart. Now head to Network Panel, filter by Websocket, select the connection and click the Frames tab.
  Now you can easily see the frames of WebSocket activity as you use the first instance of the DevTools.
</p>

<figure class="screenshot">
  <a href="{{ site.baseurl }}/images/debugger-protocol-sniffing-full.png" style="text-align: center; display:block;">
    <div style="background-image: url({{ site.baseurl }}/images/debugger-protocol-sniffing-full.png)">
      <img src="{{ site.baseurl }}/images/debugger-protocol-sniffing.png" alt="Sniffing the debugger protocol">
    </div>
    Screenshot of sniffing the DevTools protocol with DevTools
  </a>
</figure>


<h3 id="extension">DevTools protocol via Chrome extension</h3>
<p>
  To allow chrome extensions to interact with the protocol, we introduced
  <a href="https://developer.chrome.com/extensions/debugger.html">chrome.debugger</a>
  extension API that exposes this JSON message
  transport interface. As a result, you can not only attach to the remotely
  running Chrome instance, but also instrument it from its own extension.
</p>

<p>Chrome Debugger Extension API provides a higher level API where command
  domain, name and body are provided explicitly in the <code>sendCommand</code>
  call. This API hides request ids and handles binding of the request with its
  response, hence allowing <code>sendCommand</code> to report result in the
  callback function call. One can also use this API in combination with the other
  Extension APIs.
</p>

<p>If you are developing a Web-based IDE, you should implement an extension that
  exposes debugging capabilities to your page and your IDE will be able to open
  pages with the target application, set breakpoints there, evaluate expressions
  in console, live edit JavaScript and CSS, display live DOM, network interaction
  and any other aspect that Developer Tools is instrumenting today.
</p>

<p>Opening embedded Developer Tools will <a href="#simultaneous">terminate</a> the
  remote connection and thus detach the extension.
</p>

<h3 id="faq">Frequently Asked Questions</h3>

<h4 id="how-is-the-protocol-defined">How is the protocol defined?</h4>
<p>The canonical protocol definitions live in the Chromium source tree: (<a href="https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/core/inspector/browser_protocol.json">browser_protocol.json</a> and <a href="https://chromium.googlesource.com/v8/v8/+/master/src/inspector/js_protocol.json">js_protocol.json</a>). They are maintained manually by the DevTools engineering team. These files are mirrored (hourly) on GitHub <a href="https://github.com/ChromeDevTools/devtools-protocol/tree/master/json">in the devtools-protocol repo</a>.</p>
<p>The declarative protocol definitions are used across tools. Within Chromium, a binding layer is created for the Chrome DevTools to interact with, and separately the protocol is used for <a href="https://chromium.googlesource.com/chromium/src/+/lkgr/headless/README.md#client_devtools-api">Chrome Headless’s C++ interface</a>.</p>

<h4 id="whats-the-protocol_externs-file">What’s the protocol_externs file?</h4>
<p>It’s created via <a href="https://cs.chromium.org/chromium/src/third_party/WebKit/Source/devtools/scripts/build/generate_protocol_externs.py">generate_protocol_externs.py</a> and useful for tools using closure compiler. The TypeScript story is <a href="https://github.com/ChromeDevTools/devtools-protocol/issues/18">here</a>.</p>

<h4 id="are-the-http-endpoints-documented">Are the HTTP endpoints documented?</h4>
<p>Not yet. See bugger-daemon’s <a href="https://github.com/buggerjs/bugger-daemon/blob/master/README.md#api">third-party docs</a>. See also the <a href="https://cs.chromium.org/search/?q=f:devtools_http_handler.cc+%22command+%3D%3D+%22&amp;sq=package:chromium&amp;type=cs">endpoints implementation</a> in Chromium. <code>/json/protocol</code> was added in Chrome 60.</p>

<h4 id="how-do-i-access-the-browser-target">How do I access the browser target?</h4>
<p>The endpoint is exposed as <code>webSocketDebuggerUrl</code> in <code>/json/version</code>. Note the <code>browser</code> in the URL, rather than <code>page</code>. If Chrome was launched with <code>--remote-debugging-port=0</code> and chose an open port, the browser endpoint is written to both stderr and the <code>DevToolsActivePort</code> file in browser profile folder.</p>

<h4 id="simultaneous">Does the protocol support multiple simultaneous clients?</h4>
<p>
  Yes, as of Chrome 63! See <a href="https://developers.google.com/web/updates/2017/10/devtools-release-notes#multi-client">Multi-client remote debugging support</a>.
</p>
<p>
  Upon disconnnection, the outgoing client will receive a <code>detached</code> event.
  For example: <code>{"method":"Inspector.detached","params":{"reason":"replaced_with_devtools"&#125;}</code>.
  View the <a href="https://code.google.com/p/chromium/codesearch#chromium/src/out/Debug/gen/chrome/common/extensions/api/debugger.cc&q=file:debugger.cc%20Reason%20ParseReason&sq=package:chromium&type=cs&">enum of
  possible reasons.</a>
  (For reference: the <a href="https://chromiumcodereview.appspot.com/11361034/">original patch</a>).
  After disconnection, some apps have chosen to pause their state and offer a reconnect button.
</p>
